SOFTWARE LICENSE AGREEMENTS
November 2004
This Mutual Nondisclosure Agreement (the “Agreement”) is made effective as of _____________, 200__ between X and Y.
1.
Definitions.
“Confidential Information” is all (a) written information disclosed by
one party (the “Disclosing Party”) to the other (the “Receiving Party”) marked
“confidential” or with a similar legend, and (b) oral information identified as
confidential when disclosed to the Receiving Party and thereafter summarized in
a writing marked “confidential” sent to the Receiving Party within 10 days of
disclosure. The disclosure “Purpose” is
_________________. If the foregoing is
blank, the “Purpose” is to evaluate the desirability of a customer/vendor
relationship between the parties.
2.
Restrictions/Obligations. The Receiving Party: (a) may disclose the other party’s
Confidential Information only to employees who need to know; (b) shall not
disclose the other party’s Confidential Information to any third party, except
(i) to the Receiving Party’s contractors and consultants who have executed a
written nondisclosure agreement substantially as protective of the Disclosing
Party as this Agreement, or (ii) as compelled by law; (c) may use the other
party’s Confidential Information only for the Purpose; (d) shall not make an
unreasonable number of copies of the other party’s Confidential Information;
(e) shall not reverse engineer, decompile, or disassemble any software included
in the other party’s Confidential Information; and (f) shall not directly or
indirectly export the other party’s Confidential Information in violation of
the law. All Confidential Information
shall remain the Disclosing Party’s property, and all tangible copies shall be
returned (or, at the Disclosing Party’s option, destroyed) upon the Disclosing
Party’s written request.
3.
Exclusions.
Sections 2(a)-(d) do not apply to Confidential Information which: (a) is
or becomes generally known through no action or failure to act by the Receiving
Party; (b) the Receiving Party knows at the time of disclosure; (c) a third
party legitimately discloses to the Receiving Party; or (d) the Receiving Party
independently develops without using the Disclosing Party’s Confidential
Information.
4. Ownership. All Confidential Information shall remain the Disclosing Party’s property and shall be returned (or, at the Disclosing Party’s option, destroyed) upon the Disclosing Party’s written request. A Disclosing Party does not grant any license (expressly, by implication, by estoppel or otherwise) to its trademarks, copyrights or patents pursuant to this Agreement.
5. Equitable Remedies. The parties acknowledge that monetary damages may not adequately remedy an unauthorized use or disclosure of Confidential Information, and each party may, without waiving any other rights or remedies, seek injunctive or equitable relief to remedy such a breach.
6.
General. This
Agreement is governed by ____ law excluding its conflicts of laws principles. This Agreement is the entire agreement,
and supersedes all prior or contemporaneous oral or written agreements and
understandings, between the parties regarding its subject matter. The Agreement may be changed only by a
writing signed by both parties. If any
provision of this Agreement is unenforceable, that provision shall be severed
and the rest of this Agreement will continue in full force and effect.
By: By:
Title: Title:
COMMENTARY ON
NONDISCLOSURE AGREEMENTS
1.
Introduction
to Nondisclosure Agreements.
It is impossible to conduct business today without regularly encountering nondisclosure agreements (NDAs), but they remain poorly understood. All too frequently, a company instructs its field personnel to extract NDAs from business partners before conversing with them, even if an NDA is neither required nor appropriate in context. However, despite their brevity and ubiquity, both parties entering into NDAs are undertaking significant legal responsibilities, so any decision to execute an NDA should be done thoughtfully.
2.
Why
Parties Enter Into NDAs.
NDAs offer two principal benefits for a party disclosing information:
First, parties use NDAs to disclose information they want to keep a trade secret. To be a trade secret, the owner must use reasonable efforts to maintain the information’s secrecy. Contractually restricting a recipient’s use and disclosure of information satisfies that requirement. In contrast, information disclosed without the benefit of an NDA usually loses any trade secret status.
In some cases, parties may want to apply for patent protection for their trade secret information. This process is subject to specific statutory bars that preclude patent protection for any invention that has been disclosed without restriction over 1 year prior to the application’s date. Invention disclosures made pursuant to an NDA delay the commencement of the 1 year deadline, preserving the possibility of filing for patents on that invention. Without the NDA, the invention may be permanently ineligible for patent protection.
Often disclosers do not proactively determine what information they want to protect as a trade secret or by patents. Instead, organizations require NDAs from all business partners as a way to preserve future options. However, this indiscriminate use of NDAs has some risks to the discloser.
It can be hard for an information discloser to tell when an information recipient breaches an NDA. By the time the discloser realizes that a breach has occurred, the harm may be irreversible or impossible to prove.
Trade secret litigation can be expensive. Usually it requires extensive discovery by both sides and a trial on the facts (summary judgment motions are rare in trade secret litigation). It can also require significant attention from key managers and technical personnel to support the litigation, taking these employees away from higher-value projects.
Although a trade secret owner can obtain both damages and an injunction for trade secret misappropriation, these remedies can be incomplete. For example, it may be impossible to adequately capture the lost business opportunities from misappropriation of “crown jewel” assets.
NDAs also pose problems for recipients:
Usually NDAs require the recipient to restrict their use and disclosure of the discloser’s confidential information. To honor these requirements, recipients need a system to manage incoming confidential information. Otherwise, if confidential information is commingled with other information, it becomes impossible to protect adequately.
The segregation and management obligation is almost impossible with respect to information received orally. Humans simply lack the cognitive capacity to track information sources in our heads sufficiently to respect contractual commitments. However, even with respect to written documents, organizations need procedures to manage intake. Otherwise, untrained or careless employees will not comply with the obligations.
After an individual has been exposed to a third party’s confidential information, that individual can no longer “independently invent” a similar idea—any such effort will be assumed to be based on the initial trade secret. Thus, the individual becomes “tainted” by the exposure. Even if that taint does not extend to the entire organization, at minimum it can limit that employee’s usefulness and career.
The foregoing discussion suggests the following “best legal practices” regarding NDAs:
Many NDA forms define confidential information very broadly. A typical definition will designate any information provided by the discloser to the recipient as the discloser’s confidential information. Broad definitions favor disclosers because they preclude any risk of making unprotected disclosures, but in practice it is usually impossible for recipients to segregate and keep confidential all information received from a source.
This form takes a more recipient-favorable approach by defining confidential information to include only information disclosed in writing (one way or another). As a result, it becomes easier to track and protect confidential information by physically segregating the writings. In addition, the writing requirement limits the risk of a battle over what information was disclosed orally in a particular meeting. Under the proposed definition, there should be a physical record of all restricted information disclosed to the recipient.
Many disclosers object to the requirements of subpart (b). First, they object to the requirement of identifying the information as confidential prior to disclosing it. However, the announcement gives the recipient a chance to say “no thanks” before the disclosure is made. It also allows the recipient to cognitively segregate the information as confidential, increasing the likelihood that it will be honored.
Second, disclosers object to the requirement that they have to follow up in writing. As a practical matter, disclosers never follow up an oral discussion with a written document complying with this provision. Nevertheless, the post-meeting follow-up requirement creates the physical evidence trail and avoids the oral disclosure risks. Therefore, for recipients, the post-meeting follow-up requirement makes it likely that few or no oral disclosures will need to be tracked as confidential information.
Typically, the definition of confidential information is “mirror image,” i.e., the same rules apply to both parties’ information. A mirror-image provision is much easier to negotiate and does not engender bad feelings. However, in some cases, a party has significant leverage and can establish obligations that are not identically mutual. With adequate leverage, a party could force the other party to sign a “one way” nondisclosure agreement, meaning that the party with leverage gets protection for the information it discloses and the party without leverage gets no protection at all.
Alternatively, the definition of “confidential information” can be drafted where the language is not mutual, in effect giving one party much broader protection than the other party. Consider the following example language of an aggressive non-mutual clause:
With respect to [party X], “Confidential Information” means only the following enumerated items of information: _________. With respect to [party Y], “Confidential Information” means all information disclosed by Y to X, regardless of medium or format, including without limitation all information disclosed by Y to X orally, in writing and electronically and all information observed by X while X’s personnel is at Y’s facility.
The “purpose” line delimits the trade secret license. See the discussion regarding Section 2.
Every NDA is effectively a trade secret license. Section 2 defines the scope of the license.
Subpart (a) contemplates that confidential information will not be disseminated indiscriminately within the organization.
Subpart (b) restricts disclosures outside of the organization. This form has a non-standard provision allowing the receiving party to allow contractors to have access to confidential information. Usually the discloser will object to this blanket exclusion because the contractors may be competitors or untrustworthy recipients. However, as a practical reality, few organizations distinguish between employees and contractors for purposes of managing received confidential information. Therefore, the proposed text tracks the realistic data flows.
Subpart (c) restricts how the recipient uses the confidential information. Some NDAs only restrict data confidentiality and do not restrict how the recipient uses the data. Failure to restrict recipient use can be a major defect of such NDAs; without restriction, recipients could use the information to engage in competitive activities or reach other unexpected outcomes. As a result, it is usually prudent to limit the internal uses of received confidential information, such as to restrict usage to evaluating whether or not to do a transaction.
However, where a party has leverage over the other, the recipient party may not want to be restricted in how it uses information. For example, such restrictions may not be logistically practical. As a result, in cases where non-mirroring disclosure obligations can be imposed, the receiving party with leverage may wish to remove the limitations on usage (or have an unlimited purpose).
Many NDAs “expire” the Section 2 obligations after a fixed period of time. A common introductory clause might say something like “For a period of 3 years following the date of disclosure of a particular item of Confidential Information…” This clause is generally recipient-favorable because, following the expiration date, the recipient may do whatever it wants with the applicable information. This clause can lead to unexpected consequences because it also means that the discloser effectively loses trade secret protection for the disclosed information after the expiration date. However, if the NDA is solely going to cover information that has a short shelf-life (such as marketing plans), an expiration date may be appropriate.
Regarding the last sentence of Section 2, in some cases recipients may want to keep an archival copy of confidential information as evidence for future possible litigation. This strategy has some risk, as the recipient will need to maintain the confidentiality of that archival copy and could be legally liable for its mismanagement. However, should the recipient want that option, the last sentence of Section 2 should be revised accordingly.
This section effectively says that the trade secret restrictions go away if the confidential information is no longer a trade secret. Some NDAs omit this section, which is an extremely discloser-favorable result because the recipient will be bound to the NDA even if the rest of the world is not restricted in using the confidential information.
Some NDAs include an “independent development” clause. This clause reiterates that the recipient is free to develop inventions that may overlap with information disclosed to it. Section 3(d) already addresses this situation directly, but some drafters choose to reinforce this message. An example independent development clause:
The Disclosing Party understands that the Receiving Party may currently or in the future be developing information internally, or receiving information from other parties, that is similar to the Confidential Information disclosed by the Disclosing Party. Accordingly, so long as the Receiving Party complies with Sections 2 and 3 of this Agreement, a Receiving Party may freely develop information (directly or through third parties) that is similar to or competes with the Disclosing Party’s Confidential Information.
This section reiterates that a Disclosing Party is only granting a trade secret license. The provision requiring the return of confidential information works well for materials disclosed in tangible form but is impractical for materials disclosed orally or electronically and is impossible for materials retained in a person’s head.
E.
Section 5.
Equitable remedies are a typical remedy for trade secret misappropriation and thus would often follow as a matter of course in litigation over the NDA. Note, of course, that equitable remedies are at the judge’s discretion and therefore cannot be mandated by contract. Some parties choose to affect what they can by, for example, setting the amount of a bond required to obtain equitable remedies.
Some provisions that may be found in NDAs but are not included in this form.
(1) “Residuals Clauses.”
Some NDAs permit the recipient to use whatever information remains in employee’s heads without referring to written information. An example of a residuals clause:
Residuals. Notwithstanding anything in this Agreement to the contrary, the Receiving Party may use Residuals (as defined below) for any purpose, but the foregoing right does not grant any license under any of the Disclosing Party’s copyrights or patents. “Residuals” means information that is retained in the unaided memory of one or more of the Receiving Party’s employees who have had access to the Disclosing Party’s Confidential Information pursuant to this Agreement. An employee’s memory is “unaided” if the employee has not deliberately memorized Confidential Information for the purpose of retaining and later using or disclosing it.
These clauses solve the “tainted employee” problem because, in effect, employees are free to use everything in their heads. However, these clauses are, in practice, a license to steal because employees with good memories can remember a lot, and the discloser has significant evidentiary challenges proving that the recipient used written materials instead of employees’ memories.
(2) Non-Solicitation Clauses.
Some NDAs restrict a party’s ability to solicit the other party’s employees for hire. These clauses are easy to breach unless they are centrally managed, which rarely happens when they are contained in an NDA. Further, they are rarely appropriate given the introductory nature of a relationship codified solely by an NDA.
(3) Indemnity.
Sometimes disclosers will want an indemnity if the recipient breaches the NDA, but this remedy needs to be considered carefully. An indemnity clause may undermine the case for an injunction (as the clause suggests that money damages may adequately cure the breach).
Further, there are only a limited number of circumstances where an indemnity (i.e., an obligation to compensate for losses suffered to third parties) is an appropriate remedy for breach of an NDA. The most likely scenario is where X discloses Y’s confidential information, received under an NDA between X and Y, to Z, then Z breaches the X-Z NDA, and then Y sues X for the breach. While this scenario can arise, the number of situations where it would arise is small, and in those circumstances X (without the indemnity) may have substantial or full recourse against Z for losses incurred to Y.
EXAMPLE SOURCE
CODE LICENSE GRANTS
Licensor hereby grants to Licensee a perpetual, irrevocable, fully-paid, worldwide, sublicenseable (through multiple tiers) license to make, have made, sell, offer for sale, import, use, reproduce, distribute (through multiple tiers), prepare derivative works of, publicly perform and publicly display the Source Code (and any derivative works of the Source Code) in any media now known or hereafter known.
Licensor grants the foregoing licenses exclusively to Licensee, meaning that neither Licensor nor any third party may exercise any intellectual property rights in the Source Code.
The Source Code shall be deemed Licensee’s trade secret, and Licensor shall not use or disclose the Source Code for any reason.
Licensor shall deliver a complete version of the Source Code to Licensee upon execution of the Agreement.
Licensor hereby grants to Licensee a non-exclusive, worldwide (1) license to make, have made and prepare derivative works of the Source Code (either directly or through contractors), and (2) sublicenseable (through multiple tiers) license to make, have made, sell (only as incident to the license), offer for sale, import, use, reproduce, distribute (through multiple tiers), publicly perform and publicly display any executable code versions of the Source Code, in any media now known or hereafter known[, for the purpose of ______].
Confidentiality. The following provisions apply notwithstanding anything to the contrary in the Agreement. Licensee shall maintain the confidentiality of the Source Code and shall not disclose it to any third parties, except that Licensee may disclose the Source Code to third party contractors and outsourcers. The executable code versions of the Software (including user interfaces) shall not be considered Confidential Information, and Licensee may freely disclose those versions consistent with the foregoing licenses.
Licensor shall deliver a complete version of the Source Code to Licensee upon execution of the Agreement. Thereafter, Licensor shall deliver all new versions of the Source Code that the Licensor designates with a new version number (either to the left or the right of any decimal point) within 10 days of making that new version commercially available.
The “Source Code” is the Software source code and all associated materials required to enable a reasonably skilled programmer to understand the Software’s design, structure and implementation and to enable a professional writer to write documentation and help files, including without limitation any schematics or flow charts, system documentation, program procedures (including build procedures), descriptions and statements of operation and principle, programmer notes, testing data, custom or special compilers, and all other materials related to the Software’s design, structure and implementation.
COMMENTARY ON
SOURCE CODE LICENSE GRANTS
1.
Introduction.
Source code licenses can come in two types. First, a source code license can be a part of a custom development agreement, where a software developer agrees to do custom development work for the licensee. Second, the license can be made on a non-exclusive basis by a commercial software vendor in situations where the licensee needs source code access instead of an executable code version. The example clauses contemplate both types of licenses.
The development license is rather broad and onerous. This would be an appropriate license only where the software developer is never expecting to work on the software again (because the developer does not retain the license rights to do so). As a practical matter, the example license is indistinguishable from a transfer of ownership; in most cases, the parties would just structure this arrangement as an assignment (or a work made for hire). However, this license is easily modified to preserve some rights for the developer (through a grantback license, a reservation of rights or a narrowing of the license grant) while still providing robust rights to the licensee.
The commercial acquisition license applies when the vendor is offering a product to multiple customers but will provide the software in source code instead of executable code. This practice may be infrequent today but was common in the mainframe era. Because the licensor is engaged in multiple commercial transactions with customers, this license has a lot in common with executable code licenses. Readers should reference that section of the manual as well.
2.
Commentary
on Specific Provisions.
The word “hereby” makes this license grant a “present day” license grant, as opposed to a license grant that will come into effect only in the future. The present day grant avoids any risks of the license being characterized as a condition subsequent (meaning that some event has to occur before the licensee gets the rights) or being rejected in bankruptcy as an executory license.
Although these words suggest an infinitely long license grant, they have idiosyncratic legal meaning. The word “perpetual” means that the license grant lasts as long as the contract is in effect. The word “irrevocable” means that the licensee cannot revoke the license. However, 17 USC §203 says that the licensor can revoke the license in 35-40 years no matter what the contract says. So although the parties may contemplate an infinite license, and may price the license accordingly, the licensor has the absolute and unwaivable right to take back the copyrights in 35-40 years. As a practical matter, most licensees do not overly stress about this revocation right for two reasons. First, the revocation right is rarely used. Second, and perhaps more importantly, very few software programs will still be in use after 35 years, in which case the loss of the license should have minimal or no impact. As a result, the words “perpetual and irrevocable” are the best terms to try to establish an infinite license to the maximum extent the law allows.
This word contemplates that the licensee will make a one-time payment to licensor on the date of the license grant, at which point the word “fully-paid” connotes that the licensor will have no right to demand further payments for the license. If the licensor never expects payment for the license, the word “royalty-free” can be used instead. If the license contemplates ongoing or additional payments to the licensor, the word “fully-paid” is inappropriate (sometimes the words “royalty-bearing” are used instead).
This word contemplates that the licensee can exercise its rights anywhere in the world. If the license is geographically-limited, then the geographic restriction can be used instead of the word “worldwide.” Generally, however, it can be difficult to limit software usage on a geographic basis; at minimum, attempts to impose geographic limitations on software usage require careful drafting.
“Sublicenseable”
This word permits the licensee to grant sublicenses to third parties. Without a sublicensing right, the licensee may not be able to extend the benefits of the software to third parties. The “multiple tiers” language permits sublicensees to further sublicense, giving the licensee unlimited ability to distribute the software.
“Make, Have
Made, Sell, Offer for Sale, Import and Use”
This language tracks the exclusive rights of a patent owner under 35 U.S.C. §271. Using all of these words licenses all of the licensor’s rights in any patents associated with the source code.
Despite the breadth of the patent license in the example development source code license, the language does not provide any defense against a licensor’s business method patent (where the licensee uses the software as part of a larger system that implicates the patent). Sometimes licensees assume that its payments procure all rights necessary for the licensee to conduct its business. However, to effectuate that goal, the licensee needs a covenant not to sue or license to all applicable patents in licensor’s portfolio—a difficult request for most licensors to accept. The example provisions contain that broad license, so licensees should understand the risk that the licensor can still assert non-software-specific patents against the licensee.
“Use”
The word “use” serves multiple duties—it is the exclusive right under both patent and trade secret law (and trademark law, although trademarks are not an issue in these examples).
“Reproduce, Distribute, Prepare Derivative Works of, Publicly Perform and Publicly Display”
This language tracks the exclusive rights of a copyright owner under 17 U.S.C. §106. Using all of these words licenses all of the licensor’s rights in any copyrights associated with the source code.
As evidenced in the commercial acquisition provisions, “derivative works” licenses have two components. First, the license gives licensee the right to create the derivative work, and second, the license specifies the licensee’s rights to exploit the derivative work.
The second component is important because the licensee’s rights to a derivative work do not extend beyond the rights granted to the underlying work. Therefore, even though a licensee “owns” a derivative work it creates, the licensee loses all rights to exploit a derivative work if the underlying license goes away. Alternatively, if the licensee’s rights to exploit the underlying work is limited, those limitations apply to derivative works as well.
The development source code license does not contain an express second component license because the license grant covers the underlying source code and any derivative works equally.
“In any media now known or hereafter known”
Some courts have struggled with interpreting license grants when new media emerge that the parties did not contemplate at the time of their license. In some cases, the courts have limited a licensee’s rights to exploit the work in the new medium. This language would remove any doubt that the parties intended that the licensee’s rights apply in all media, even if no one has contemplated a particular medium at the time of contracting.
Exclusivity
The word “exclusive” is inherently ambiguous. At minimum, it can be unclear if the exclusivity applies to the licensor (in other words, does the licensor retain any rights to exploit the licensed works?). As a result, it is generally useful to define what the word “exclusive” means.
In the development source code license, exclusivity is defined broadly to apply to the licensor and all third parties and to cover all rights. As drafted, the licensee has obtained all of the intellectual property rights to the source code, and the licensor has retained no rights. Thus, for example, the licensor cannot develop or maintain the source code because the licensor has transferred the IP rights it needs to do so. In most cases, the licensor will retain some rights, in which case the exclusivity clause will be scaled back (or other parameters, like the license duration or geographic scope, will be narrowed).
Deeming the source code Licensee’s trade secret
The development source code license deems the source code to be licensee’s trade secret. This clause is appropriate where the licensor is doing custom development work and the licensee is acquiring the equivalent of ownership. Without this provision, there may be narrow circumstances where the licensor could disclose the trade secrets in the source code without violating the exclusive license grants. This clause plugs those holes.
If the licensor retains rights to the source code, the licensor may demand confidentiality from the licensee so that the licensor can also sue competitors or hackers for misappropriation. Any such confidentiality promise from the licensee to the licensor must otherwise be consistent with licensee’s rights under the license grant.
Purpose
The commercial acquisition license grant contemplates that the licensor will allow the licensee to use the software only for a particular purpose. Licensees would generally prefer not to be restricted to just one purpose; this language would require the licensee to procure additional rights (probably at additional expense) if it wants to use the software for new purposes. However, this license grant contemplates that the licensee can freely distribute executable code versions, and the “purpose” limitation prevents the licensee from cannibalizing licensor’s sales.
Commercial
Acquisition Confidentiality
Often licensors designate the source code as “confidential information” in the confidentiality clause. This is generally suboptimal because the confidentiality clause may be inconsistent with the license grant. The better approach is to separately state the confidentiality provisions directly applicable to the source code, rather than generically treating the source code like other types of confidential information.
This particular clause provides differential treatment between source code (where a human looking at the code could gain some insights about how to draft similar code) and executable code, where the coding is opaque to viewers. Here, the provision prevents the licensee from disclosing the source code (which could suppress demand from other potential licensees), while allowing the licensee to freely disclose the executable code versions.
Definition of Source Code
The definition should include more than just the literal code itself. Often, recipients of code cannot easily navigate through source code without some guidance. As a result, the definition of the source code includes supporting material beyond the literal code itself that will facilitate/expedite a person’s review and understanding of the software.
Often, the licensor includes third party components into its software. In some cases, the licensor will not have source code copies of these components or will not have the right to redistribute those components. Therefore, licensees should ask pointed questions to the licensor about these components to understand whether the source code delivered by the licensor will, in fact, be “complete.”
Delivery
Obligations
A license grant to source code and licensor’s obligation to deliver source code are not co-extensive. A license grant does not obligate licensor to deliver source code, and delivery of source code does not inherently grant a license to use the source code. Therefore, license grants and delivery obligations both must be articulated.
The example language contemplates a new delivery of source code after every new numbered version. Developers often number each software release using a construct X.Y (or sometimes X.Y.Z). Normally an increase in X represents a new version of the software, where an increase in Y or Z represents a less significant change (like an upgrade, an update or a bug fix). In many support agreements, new versions with a change to X are not provided free-of-charge, while new versions with changes to Y or Z are covered under the support fee. The example language assumes that the licensee gets everything at no cost.
If the licensee makes changes to the initially-delivered source code, subsequent versions of the source code may not be useful because it may be cost-prohibitive for the licensee to reimplement those changes in a new version.
3.
Other
Considerations.
Grantback License
In some cases, the licensor will want a license to/delivery of any modifications made by licensee. To the extent the licensor wants the modifications because it will incorporate those modifications into its base code, this can be a good or bad thing. The good news is that such incorporated code then could be supported by the licensor, keeping the licensee on the support program. The bad news is that all of the other licensees would get the modification’s benefit, which could have competitive or other disadvantages.
At minimum, many licensors will want a grantback license to avoid a “blocking patent.” The licensee can patent the improvements it makes to the licensor’s code, which could block the licensor from independently making those same improvements without obtaining a license from the licensee. To avoid the potential hold-up game that could ensue, or the need to redesign their product from the most logical progression to some lesser route, many licensors will want the license to any modifications as a condition of granting access to the source code. Grantback licenses are negotiable, however, and are not found in every source code license.
EXAMPLE
EXECUTABLE CODE LICENSE GRANT
Licensor hereby grants to Licensee a non-exclusive license to:
[Server
components] install and use the [server components of the] Software on
servers operated by or on behalf of Licensee;
[Client
components] (i) copy and use the [client components of the] Software, and
(ii) distribute the [client components of the] Software to third party
contractors and vendors and permit them to copy and use the [client components
of the] Software to interact with Licensee’s server;
[SDK] (1) copy and use the SDK, (2) distribute the SDK to third party contractors and permit them to use the SDK for Licensee’s benefit, (3) prepare derivative works of the SDK by incorporating elements into Licensee’s software, and (4) perpetually and irrevocably make, have made, use, sell, offer for sale, import, reproduce, distribute, prepare derivative works of, publicly display and publicly perform Licensee’s software with the SDK components incorporated into it;
[Documentation] (1) copy and use the Documentation, (2) distribute the Documentation to third party contractors and permit them to use the Documentation, (3) prepare derivative works of the Documentation, and (4) perpetually and irrevocably make, have made, use, sell, offer for sale, import, reproduce, distribute, prepare derivative works of, publicly display and publicly perform any derivative works of the Documentation.
In addition to the
foregoing licenses, Licensee may make backup and archival copies of the
Software in accordance with Licensee’s normal business practices.
Confidentiality. Notwithstanding anything to the contrary in this Agreement, Licensee may disclose the Software to third party contractors and any outsourcers, so long as Licensee requires those parties to maintain the Software’s confidentiality to the same degree the Licensee is required to maintain confidentiality. Otherwise, except to the extent that the foregoing licenses permit redistribution of Software components, Licensee shall not disclose the Software to third parties.
COMMENTARY
ON EXECUTABLE CODE LICENSE GRANT
1.
Introduction.
This example covers situations where the licensor is providing executable code versions of its software to licensee. By necessity, this example is incomplete because it does not tie the license grant to the royalty/payment structure. Licensors use a wide variety of pricing mechanisms: per-copy, per-CPU, per-named individual, per-record, per-transaction, all-you-can-eat for a fixed period of time, etc. These mechanisms will likely affect the specific restrictions contained in the license grant as the licensor tries to tie the license to its ability to get paid.
Many software packages contain multiple components subject to different restrictions. For example, a typical client/server software package may consist of three distinct components: (a) a server component that is usually subject to significant restrictions on copying and exposure to third parties; (b) a client component that may be less restricted (in some cases, freely distributable without any license fees to licensee’s employees and even third parties), and (c) a developer toolkit (often called a “Software Development Kit” or “SDK”) that the licensee may use to build new applications, where in some cases the new applications will contain portions of the toolkit in it. In addition, the licensor often provides documentation describing the software and how to troubleshoot problems.
Unfortunately, many sloppy licensor form agreements do not clearly distinguish between these components, masking differential rights that the licensee should be getting. To properly analyze a license agreement, the licensee must clearly understand the constituent components of the in-licensed software and ensure that the applicable components are adequately characterized in the license agreement. The example license grant assumes a multi-component software license grant and provides differential license grants for each component.
Licensees should also remember that software licenses take a variety of forms, including “shrinkwraps” and “clickwraps” (a/k/a clickthrough agreements), and those forms are usually binding as a matter of contract law. As a result, licensees entering into these contracts should carefully consider those contracts using the principles in this manual.
2.
Commentary
on Specific Provisions.
Definition of “Licensee”
In some cases, such as a corporation with no subsidiaries or affiliates, defining the licensee is relatively easy. However, with more complex organizational structures, the definition of licensee can have significant substantive effect.
From the licensee’s perspective, the licensee wants as broad a definition of “licensee” as possible. This has two benefits: first, all named parties will benefit from the license at the price stated in the contract, and second, the licensee does not need to go through any formalities (such as written sublicenses) to extend the contract’s benefit to these third parties.
From the licensor’s standpoint, expanding the scope of the license has two downsides. First, the additional parties may have represented possible customers for the licensor, so this contract consolidates two (or more) sales into a single sale—potentially reducing the total dollar value the licensor is extracting from this group of customers. Of course, the contract’s pricing mechanism can be used to cure this problem, although licensors frequently misunderstand this point. The only exception is where the licensor provides volume discounts that may be more easily reached if more entities participate under the same contract (but many licensors would be thrilled to have this problem!).
The second licensor downside is that the licensor may lack contractual privity to sue non-signatories for breach of contract—leaving the licensor with remedies only against the signatory. If the signatory has deep pockets, this may not be a pressing concern, but conservative licensors do not feel comfortable having their commercial products in the hands of people not bound by contractual privity.
Typically, an expansive definition of “Licensee” includes the licensee and all “affiliates.” Affiliates can be defined as “any person or entity that controls, is controlled by, or is under the common control” of the licensee. If “control” needs to be defined, it can mean 50% of the voting stock of an entity. In some cases, licensees will lower that threshold to track accounting consolidation.
License to Server Components
Typically licensors can restrict a licensee’s ability to install server software on a variety of dimensions, such as restrictions on the number of servers, the identity of the servers, the geographic/physical location of the servers, the number of CPUs associated with the servers, etc. Depending on the licensor’s revenue models, such restrictions may need to be included. If those requirements are not needed, the example grant provides significant flexibility to the licensee by not limiting the number of copies and by permitting outsourcing.
License to
Client Components
As with the server components, licensor revenue models may dictate the appropriate scope of this license. Thus, for example, many licensors charge a per-copy fee for client software, and thus may restrict copying accordingly. The example license is licensee-friendly because it permits licensee to make unlimited copies. Further, the example license allows the licensee to extend the software functionality to third parties (like vendors and contractors). In some cases, licensors will want to treat those third parties as sublicensees and require the licensee to enter into written sublicenses with these sublicensees containing licensor-specified minimum terms. Licensees should try to avoid committing to these formalities, which are difficult to manage, although there are good reasons for the licensor to want some contractual privity with the parties receiving copies through licensee.
License to Software Development Kits (SDKs)
SDK licenses can be confusing because SDKs can have a variety of functions. Common functions include:
· Allowing the licensee to customize the software without changing the source code.
· Providing an “application programming interface” (API) which allows the licensee to write software programs that interact with the software without seeing the underlying source code. APIs often provide a set of rules for how the software processes incoming data. Thus, the external programs can be customized to transmit data to the software conforming to those rules.
· Including snippets of software code—source code or executable code—that the licensee can incorporate into other programs that allow those other programs to interact or communicate with the software. In these situations, the licensee needs the right to distribute these snippets with other programs. If the snippets are in source code, the licensee may also need the ability to modify the snippets to plug them in correctly.
Because of the disparate ways in which SDKs can operate, the example license provision may be overinclusive for a particular circumstance.
As with the other components, in some cases the licensor charges licensees based on SDK usage—such as the number of individuals who can use the SDK. Appropriate adjustments may need to be made to the license grant.
License to Documentation
The documentation license looks a lot like the SDK license. It contemplates that licensee can make its own copies of the documentation and distribute them to software users. It also contemplates that the licensee may create custom/proprietary versions of the documentation, and it can disseminate these versions as well.
Backup and Archival Copies
Many licensors restrict licensees to making only one backup or archival copy. The licensor is usually concerned that these copies will end up being used for productive purposes without adequate compensation. However, in practice computers are often backed up multiple times, so the limit to a single copy is neither realistic nor necessary.
Confidentiality
The confidentiality provisions of a License Agreement can often conflict with the license grants in the document, creating ambiguities that may restrict the license. As a result, this language provides some confidentiality assurances that should negate any need for separate confidentiality obligations elsewhere in the document that apply to the software. The example language expressly harmonizes the license grant and the confidentiality obligations. It also permits disclosure of the software to contractors and outsourcers, which many confidentiality clauses would not otherwise permit.
3.
What’s
Missing?
Many licensor-drafted license agreements will contain some of the following language. This section explains why this language is not licensee-favorable.
“Non-Assignable”
/ “Non-Transferable”
Some licensor grants say that the license is “non-assignable” or “non-transferable.” Restricting the licensee’s right to assign the license can be appropriate when the licensee obtains an enterprise license; in many other cases, assignment restrictions are neither necessary nor appropriate. Even where the parties agree to restrict assignment, it avoids ambiguity and conflict to put all restrictions on assignment in a standalone clause addressing the contract’s assignability as a whole.
The phrase “non-transferable” in the license grant is ambiguous. The phrase can be read to restrict both contract/license assignment and sublicenseability. Usually, this phrase is superfluous to other restrictions, and often it directly contradicts other portions of the agreement. As a result, this phrase should usually be struck.
“Limited”
Some license grants will state that the license is “limited.” This word is ambiguous. Either the limitations are expressly spelled out in the license grant, in which case this word is superfluous, or the court will interpolate additional unstated restrictions into the license, in which case this word has unpredictable substantive effect. Because of its ambiguity, this word should be struck.
License to use
for “Internal Business Operations”/“No Service Bureau”
Many licensors permit the licensee to use the software only for internal business operations. Sometimes this is stated as a restriction against using the software in a service bureau operation. The concern is that if a licensee can use the software to benefit third parties, the licensor’s first customer could be its last—all future customer prospects for the software might ask the first licensee to perform a service for them as a substitute for licensing the software directly.
In some cases, this is a bona fide concern, especially for licensees who routinely operate service bureau, outsourcing or application service provider (ASP) businesses. However, in other cases, the licensor may fully understand and expect that the licensee is going to use the software for a third party’s benefit and has built the pricing/royalty provisions accordingly. Therefore, this language needs to be carefully scrutinized to assess its applicability to a particular transaction.
EXAMPLE
SOURCE CODE ESCROW PROVISIONS
Include in the
Escrow Agreement
Release Conditions. The Escrow Agent shall deliver the escrow contents to Licensee upon the occurrence of any of the following conditions:
· [1] Licensor has filed, or has filed against it, any proceeding in bankruptcy or for reorganization under any federal or state bankruptcy law; any receivership of all or a substantial part of its assets or business; any assignment for the benefit of creditors; or any other proceeding for debt relief;
· [2] Licensor becomes insolvent;
· [3] Licensor announces that it will no longer conduct business in the ordinary course, or actually stops doing so;
· [4] Licensor materially breaches the License Agreement and fails to cure such breach within __ days following notice;
· [5] Licensor does not cure an error or bug experienced by Licensee within the following time frames: critical bug—1 day; severe bug—1 week; serious bug—1 month;
· [6] Licensor announces that it is no longer providing maintenance/support for the Software.
Escrow Contents. The escrow contents shall include, at minimum, the source code of the Software and all associated materials required to enable a reasonably skilled programmer to understand the design, structure and implementation of the Software and to enable a professional writer to write documentation and help files, including without limitation any schematics or flow charts, system documentation, program procedures (including build procedures), descriptions and statements of operation and principle, programmer notes, testing data, custom or special compilers, and all other materials related to the design, structure and implementation of the Software.
Supplementary Agreement. Licensor and Licensee acknowledge that this Escrow Agreement is an “agreement supplementary to” the License Agreement as provided in Section 365(n) of Title 11, United States Code (the “Bankruptcy Code”). Licensor acknowledges that if Licensor (as a debtor in possession), or a trustee in bankruptcy (in a case under the Bankruptcy Code), rejects the License Agreement or the Escrow Agreement, Licensee may elect to retain its rights under the License Agreement and the Escrow Agreement as provided in Section 365(n) of the Bankruptcy Code. At the Licensee’s request, neither Licensor nor a bankruptcy trustee shall interfere with Licensee’s rights in the License Agreement and the Escrow Agreement, including the right to obtain the source code from the escrow agent.
Include in the
License Agreement
License. Licensor hereby grants to Licensee a perpetual, irrevocable, non-exclusive, fully-paid, sublicenseable license to use, reproduce and prepare derivative works of the Software source code to fix and enhance the Software, either directly or through third party contractors under confidentiality obligations. [Licensee agrees not to exercise the foregoing license until the occurrence of a release condition specified in the Escrow Agreement.] For purposes of the license grant and confidentiality, the source code and all modifications and derivative works of the Software source code shall be included in the definition of “Software” in the License Agreement.
Rights in Bankruptcy. All rights and licenses granted to Licensee
pursuant to this License Agreement (other than with respect to trademarks) are,
for purposes of Section 365(n) of the Bankruptcy Code, licenses of rights to
“intellectual property” as defined by Section 101 of the Bankruptcy Code. As a result, Licensee shall retain and may
fully exercise all of the rights and elections under the Bankruptcy Code. In the event of the commencement of a bankruptcy
proceeding by or against Licensor under the Bankruptcy Code, Licensee shall be
entitled to a complete duplicate of (or complete access to) any such
intellectual property and all embodiments of such intellectual property. All such duplicate materials shall be
promptly delivered to Licensee at Licensee’s request at any time following (1)
the commencement of the bankruptcy proceeding (unless Licensor elects to
continue performing the License Agreement), or (2) Licensee’s rejection of this
License Agreement.
COMMENTARY
ON SOURCE CODE ESCROW PROVISIONS
1.
Introduction.
A.
Why Do an Escrow Agreement?
The source code escrow has become a standard way for licensors and licensees to “split the baby” regarding the risk of unexpected developments. The escrow gives the licensee the feeling that it can get the source code if necessary, while the escrow gives comfort to the licensor that its crown jewel assets will not be posted to the Internet immediately after signature.
As a practical matter, escrows rarely serve these objectives. First, the formalities required to release the escrow contents means one party assumes some risk. A licensee-favorable release trigger would instruct the escrow agent to release the materials merely upon the licensee’s certification that a release event has occurred. However, few licensors will agree to such favorable provisions because a bad faith licensee could force an escrow release even if the release conditions have not occurred. Even if the licensor agrees to such a licensee-favorable release condition, the licensor can still seek a TRO to prevent the release from occurring, which at minimum could slow down the release until it is too late.
More typically, the release formalities allow licensors to veto any release, thus forcing the licensee to pursue legal recourse (in court or arbitration) to get any release. This almost always ensures that the licensee’s access to the escrow materials will be too late to be useful.
A truly licensee-favorable approach is to avoid the escrow intermediary altogether. Instead, the licensee should take possession of the material on contract signing and contractually agree not to look at it. However, almost all licensors will vehemently object to this approach, and some licensees may worry about their potential liability if they mismanage the material in their possession.
When licensees succeed in getting material released from an escrow, they are often disappointed. Many licensors fail to keep their escrowed materials up-to-date, meaning that the escrow contains only outdated and unhelpful versions of the source code. This problem is theoretically easy to avoid—licensee can simply designate someone to monitor and badger the licensor—but few licensees go through this hassle; and even if they did, most escrow companies do not confirm that the licensor is, in fact, depositing the latest versions (they merely notify licensees when new material has been deposited).
As this introduction explains, escrow agreements rarely accomplish their purported goals. Licensees who want real security should avoid escrow arrangements.
B.
Escrow Release and Licensor Maintenance/Support.
A source code release may affect the licensee’s ability to obtain software support from the licensor. If the licensee “branches off” from licensor’s source code using the released material, licensors may stop providing bug support for licensee’s software because the licensor cannot determine if a bug is attributable to licensor’s code or a licensee modification. Similarly, licensees who branch off may not want new executable code versions of the software because the licensee will not be able to integrate the changes to the new version.
The fact that an escrow release may cost the licensee future software support raises the stakes for a licensee’s decision to access the escrow. When the licensor has not committed a serious faux pas and the release will eliminate future support that the licensee needs, many licensees will decide not to access the escrow.
2.
Commentary
on Specific Provisions.
Release Conditions 1, 2 and 3
Typically, escrow releases are triggered by a licensor’s bankruptcy. However, clauses that trigger rights/obligations upon a party’s bankruptcy are generally unenforceable, so there remains some risk that the clause will not work as stated. As a result, savvy licensees will try to effectuate an escrow release prior to bankruptcy if possible. An insolvency release condition can permit this; often licensors will become insolvent before declaring bankruptcy, and if the licensee can time it correctly, the licensee can get the escrow release after insolvency but before bankruptcy.
However, it can be difficult to determine a licensor’s solvency. As a monitoring tool, some licensees require periodic financial disclosures from the licensor, but licensees must then confirm delivery of the disclosures and actually review them to assess insolvency. While this effort is rarely cost-justified, the insolvency release condition remains a useful clause to have.
Release condition 3 has some additional benefits. Not all licensors use bankruptcy to shut down, and a release condition based on an announcement of shutting down significantly moves up the release date (potentially in advance of possible bankruptcy).
Releases
Conditions 4, 5 and 6
The principal reason why a licensee wants access to the source code is to correct bugs, facilitate integration of the software with licensee’s system, and in some cases extend the functionality of the software. Release conditions 4, 5 and 6 all address this issue directly.
Release condition 4 gives the licensee access to the source code when the licensor is in breach of the license agreement. (In some cases breaches of complementary agreements, such as a development agreement or a support agreement, are appropriate additional triggers for the release condition). In practice, this release condition may largely overlap with other release conditions but it gives the licensee one more way to get source code out of escrow prior to bankruptcy. The blank should be filled in with the cure period in the License Agreement—so that in the case of an uncured breach, the licensee can both terminate and trigger an escrow release simultaneously.
Release condition 5 is a logical trigger for giving licensee the right to fix bugs that the licensor is not fixing. The references to critical/severe/serious bugs often will be defined in the support agreement, and those definitions should be used instead of the example’s placeholder language.
Some licensors will object to releases based on non-critical bugs. Many licensees will choose not to trigger the escrow for non-critical bugs if it will cost them future support. However, this provision permits the licensee to get the source code to fix a persistent bug that the licensor is not willing to (or cannot) fix.
Although it is less controversial that the licensee should get the escrow materials if the licensor cannot fix a critical bug, this remedy is not very useful. It seems very unlikely that, in response to a critical bug, a licensee will on a timely basis get source code, understand it and create a solution that the licensor overlooked. Nevertheless, a critical bug may be mission-critical to licensee and a lower priority to the licensor, so the availability of source code in critical situations may correct the imbalanced motivations.
Unlike release condition 4, release condition 5 does not provide any additional “cure” periods to licensor. If the licensor misses the pre-specified window to fix bugs, it should not get an additional cure period.
Release condition 6 applies to a situation where the licensee knows that it will have to maintain the software on its own. In that case, the licensee would prefer to get the source code at the earliest possible opportunity due to the ramp-up period of learning how the source code works.
Supplementary Agreement
Section 365(n) of the Bankruptcy Code limits the ability of a licensor or its trustee to reject “supplementary agreements.” This language, while a little self-serving, merely expressly states what a court would likely determine in any case. As a result, few licensors should object to this language.
License
Many source code escrow agreements erroneously draft the license so that it does not come into existence until after the source code has been released out of escrow. This delayed license raises a risk that the bankruptcy trustee could reject the license as an executory obligation. The better approach is for the license to take effect upon signing of the license agreement. In this case, the license is already in place when the licensor enters bankruptcy. This “present-day” grant of a license has no meaningful consequence for the licensor, as the licensee cannot actually exercise the license without possession of the source code. However, to the extent that the language causes licensors to panic, the licensee can include the bracketed language as a contractual commitment to defer taking advantage of the license until a release condition occurs.
In many cases, the licensee will not actually maintain the software itself; instead, the licensee will seek out a third party contractor to provide ongoing support as a service. Alternatively, the licensee may retain independent contractors to provide ad hoc expertise. Either way, the license grant and the confidentiality clause should be drafted to ensure that the licensee can provide a copy of the source code to these third parties.
The last sentence ensures that the licensee has adequate licenses to any works it creates using the source code and also provides the licensor some confidentiality protection for those works (co-extensive with the amount of confidentiality already applicable to the software generally).
Many licensors will require the licensee to commit to substantially more extensive confidentiality obligations regarding the source code than the executable code. Licensees should consider the confidentiality restrictions carefully to ensure they match their expected needs and behavior.
Rights in Bankruptcy
The paragraph essentially restates the law in Sec. 365(n). Including it in the contract helps a bankruptcy judge recognize the issue, but otherwise it is largely self-serving. Nevertheless, because it tracks the default rules, few licensors should object to including the language.